System and method for dynamically tuning interrupt coalescing parameters

ABSTRACT

A system and method for dynamically tuning the interrupt coalescing behavior of a communication interface. An interrupt handler adjusts dynamic Packet and/or Latency values to control how many packets the interface may accumulate, or how much time the interface may wait after receiving a first packet, before it can signal a corresponding interrupt to a host processor and forward the accumulated packet(s). The interrupt handler maintains a Trend parameter reflecting a comparison between recent sets of packets received from the interface and the Packet parameter. The Packet value is decreased or increased as packet traffic ebbs or flows. When the Packet value is incremented from a minimum value, a Fallback mechanism may be activated to ensure a relatively rapid return to the minimum value if an insufficient amount of traffic is received to warrant a non-minimum Packet value. The Latency value may be increased as the processor&#39;s workload increases.

RELATED APPLICATION

[0001] This application is a continuation-in-part of U.S. applicationSer. No. 10/125,196, filed Apr. 18, 2002, which is hereby incorporatedby reference.

BACKGROUND

[0002] This invention relates to the field of computer systems. Moreparticularly, a system and methods are provided for dynamicallyadjusting parameters of a communication interface, in response to adynamic measurement of the interface workload, to modify the manner inwhich the communication interface coalesces interrupts associated withthe forwarding of communications to a host processor.

[0003] When a communication interface (e.g., a network interfacecircuit, or NIC) receives a packet, frame or other communication from acommunication link, it is usually configured to notify a host processorvia an interrupt. In early network interfaces, a separate interrupt mayhave been issued for each packet the interface received from the networkand forwarded to the host. As long as data rates were low, packets wouldarrive relatively infrequently, and a host processor would not beoverwhelmed.

[0004] However, at today's data rates (e.g., 1 gigabit per second andhigher), if a separate interrupt were issued by a network interface forevery packet it received and passed to a host processor, it would signalmore than 80,000 interrupts per second. Even a modern, high-performance,processor, if besieged with so many interrupts, would likely beincapable of processing them and switching in and out of aninterrupt-processing mode, while still handling normal processing tasks.

[0005] One method of decreasing the number of interrupts issued by acommunication interface to a host processor is called interrupt blankingor interrupt coalescing. With interrupt blanking, a communicationinterface may accumulate multiple packets before issuing an interrupt toa host processor. Illustratively, when the communication interfacereceives a first packet, it initiates a packet counter and a latencytimer. When either a predetermined number of packets is accumulated or apredetermined period of time elapses, all of the accumulated packets aresent to the host and one interrupt is signaled.

[0006] Interrupt blanking or coalescing has typically been implementedsolely within the communication interface hardware. The parameters thatdetermine when an interrupt may be issued (i.e., maximum packet count,maximum latency) were static parameters programmed into thecommunication interface before or during its initialization. Theparameters could not be changed without resetting the interface anddisrupting the communication flow through the interface.

[0007] Thus, the parameters for controlling interrupt blanking must beconfigured before the pattern of traffic to be handled is known. At oneextreme, the traffic may be relatively heavy; at the other, the trafficmay be relatively light. A heavy traffic pattern is typical of thetransfer of a large amount of data, and involves the receipt of manyseparate packets relatively close in time. A light traffic pattern,involving the receipt of relatively few packets, spread out over time,may be indicative of a request-response communication flow between aclient and a server, or other entities.

[0008] If a communication interface was optimized for one type oftraffic, it would necessarily handle the other type inefficiently. Thus,configuring the interrupt blanking parameters for a high packet countand high latency would allow for efficient handling of a large amount ofdata, but would provide poor performance for a request-response flow. Alow packet count and low latency would entail the opposite. Thus, theparameters have typically been optimized for either heavy or lighttraffic, thereby handling the other type very ineffectively, or havebeen set to median values, in which case both types are handled equallyinefficiently.

[0009] Because interrupt blanking parameters have been static, as thetraffic received by a communication interface varied from what it wasoptimized for, performance would vary commensurately. The parameterscould not be dynamically configured to meet the changing trafficpattern.

SUMMARY

[0010] Therefore, in one embodiment of the invention, a system andmethods are provided for dynamically modifying the interrupt blanking(or coalescing) behavior of a communication interface, in response tothe changing workload or traffic pattern received at the interface. Inan embodiment of the invention, an interrupt handler or device driverdynamically adjusts IMFC (Instantaneous Maximum Frame Count) and/or IML(Instantaneous Maximum latency) values on the communication interface.IMFC and IML control, respectively, how many frames the interface mayaccumulate, or how much time the interface may wait after receiving afirst frame, before signaling a corresponding interrupt and forwardingthe accumulated packet(s). The interrupt handler maintains a Trendparameter reflecting a comparison between recent sets of frames receivedfrom the interface and the interface's IMFC parameter at the time of theinterrupts. The IMFC value is decreased or increased as a flow of framesebbs or flows.

[0011] In one embodiment of the invention, when IMFC is incremented froma minimum value, a fallback mechanism is activated to ensure arelatively rapid return to the minimum value if an insufficient amountof traffic is received to warrant the higher IMFC value. While thefallback mechanism is active, IML may be set at lower than normalvalues. When the fallback mechanism expires, IML may be reset to adefault or normal value.

[0012] During each interrupt serviced by the interrupt handler, one orboth IMFC and IML may be written to the communication interface tooverwrite previous values and control the interrupt coalescing behaviorof the interface.

[0013] In another embodiment of the invention, the status (e.g.,workload) of a processor that executes the interrupt handler or devicedriver may be considered when adjusting an interrupt coalescingparameter. In this embodiment, the percentage of time that the processoris idle or waiting for a task is compared to one or more thresholds. Inone implementation, as the proportion of time that the processor is idledecreases below a first threshold (e.g., 50%), IML (and/or IMFC) may beincreased to increase the time between successive interrupts.

DESCRIPTION OF THE FIGURES

[0014]FIG. 1 is a block diagram depicting a computing environment inwhich an embodiment of the present invention may be implemented.

[0015]FIG. 2 is a flowchart demonstrating one method of dynamicallyadjusting interrupt coalescing parameters of a communication interface,according to one embodiment of the invention.

[0016]FIG. 3A is a graph demonstrating a “hunting” pattern of interruptcoalescing parameter adjustments that may be observed with oneembodiment of the invention.

[0017]FIG. 3B is a graph demonstrating an attenuated “hunting” patternof interrupt coalescing parameter adjustments that result fromimplementation of a fallback latency sensitivity (FLS) mechanism,according to one embodiment of the invention.

[0018] FIGS. 4A-B comprise a flowchart demonstrating a method ofdynamically adjusting interrupt coalescing parameters of a communicationinterface while implementing an FLS mechanism, according to oneembodiment of the invention.

[0019]FIG. 5 is a flowchart demonstrating a method of dynamicallyadjusting an interrupt coalescing parameter of a communication interfacein accordance with the workload of a host processor configured toreceive interrupts from the communication interface.

DETAILED DESCRIPTION

[0020] The following description is presented to enable any personskilled in the art to make and use the invention, and is provided in thecontext of particular applications of the invention and theirrequirements. Various modifications to the disclosed embodiments will bereadily apparent to those skilled in the art and the general principlesdefined herein may be applied to other embodiments and applicationswithout departing from the scope of the present invention. Thus, thepresent invention is not intended to be limited to the embodimentsshown, but is to be accorded the widest scope consistent with theprinciples and features disclosed herein.

[0021] The program environment in which a present embodiment of theinvention is executed illustratively incorporates a general-purposecomputer or a special purpose device such as a hand-held computer.Details of such devices (e.g., processor, memory, data storage, display)may be omitted for the sake of clarity.

[0022] It should also be understood that the techniques of the presentinvention may be implemented using a variety of technologies. Forexample, the methods described herein may be implemented in softwareexecuting on a computer system, or implemented in hardware utilizingeither a combination of microprocessors or other specially designedapplication specific integrated circuits, programmable logic devices, orvarious combinations thereof. In particular, the methods describedherein may be implemented by a series of computer-executableinstructions residing on a suitable computer-readable medium. Suitablecomputer-readable media may include volatile (e.g., RAM) and/ornon-volatile (e.g., ROM, disk) memory, carrier waves and transmissionmedia (e.g., copper wire, coaxial cable, fiber optic media). Exemplarycarrier waves may take the form of electrical, electromagnetic oroptical signals conveying digital data streams along a local network, apublicly accessible network such as the Internet or some othercommunication link.

[0023] In one embodiment of the invention, a system and method areprovided for dynamically adjusting operating parameters of acommunication interface (e.g., a network interface circuit or NIC), inresponse to a dynamic measure of communication traffic through theinterface, to alter the frequency with which interrupts are issued bythe interface to a host processor. In this embodiment, the adjustableparameters are used to determine how many communications (e.g., frames,packets) the interface may accumulate, or how long a period of time towait after receipt of a first interrupt, before another interrupt may beissued.

[0024] The parameters that are adjusted in an embodiment of theinvention may be collectively termed “interrupt coalescing parameters.”In embodiments of the invention described herein, the individualparameters may be termed IMFC (Instantaneous Maximum Frame Count) forthe number of communications the interface may accumulate before issuingan interrupt, and IML (Instantaneous Maximum latency) for the amount oftime the interface may wait, after receiving a communication, beforesignaling an interrupt.

[0025] In an embodiment of the invention, an interrupt handler or devicedriver called by a host processor (e.g., in response to an interruptfrom the communication interface) is configured to examine a workload orpattern of communications received through the interface and dynamicallymodify the interface parameters to suit that workload. For example, ifthe number of communications is consistently high, the interrupt handlermay increase the interface's IMFC parameter; if the number ofcommunications is decreasing or steadily low, the interrupt handler maydecrease IMFC.

[0026]FIG. 1 depicts a computing environment in which an illustrativeembodiment of the invention may be implemented. In FIG. 1, computers106, 108, 110 are interconnected via network 140, which may comprise theInternet. Computer 110 comprises processor 112 and network interface116. Network interface 116 includes, for purposes of an embodiment ofthe invention, packet counter 118 and timer 120.

[0027] Illustratively, packet counter 118 comprises a hardware registeror operating parameter for storing an IMFC value computed for networkinterface 116 by interrupt handler 114 (when executed by processor 112).Similarly, timer 120 comprises a register or parameter for storing anIML value computed by the interrupt handler.

[0028] In an alternative embodiment of the invention, network interface114 may be any communication interface that employs parameters that canbe adjusted to affect the generation of interrupts. Another alternativeembodiment may be implemented in a computer comprising multiplecommunication interfaces handling the same or different types oftraffic. Thus, an embodiment of the invention may be implemented forwired and/or wireless communications formatted according to anycommunication protocol(s), such as Ethernet, TCP/IP, ATM (AsynchronousTransfer Mode), WAP (Wireless Access Protocol) and so on.

[0029] In an embodiment of the invention, an interrupt handler or devicedriver (e.g., interrupt handler 114 of FIG. 1) determines appropriatesettings for the IMFC and/or IML parameters of a communication interfaceas frequently as every interrupt it services. In other embodiments, someother frequency may be applied (e.g., every other interrupt). Theparameters are set according to trends it detects in traffic receivedfrom the interface and/or the status (e.g., workload) of a hostprocessor. If multiple communication interfaces are employed in onecomputer system, whether they are serviced by one interrupt handler orby different handlers, the interrupt coalescing parameters of eachinterface may be set independently of the other(s).

[0030] To limit or restrict the range of values that can be assigned toIMFC and/or IML, one or more operating parameters may be exposed to auser for suitable configuration. For example, in one embodiment of theinvention, a user may set a “maximum_packets” parameter to serve as anupper bound on IMFC. A user may also be able to set a “maximum_latency”parameter to serve as an upper bound on IML. In one implementation ofthis embodiment, a default value for maximum_packets is twenty-four,while a default value for maximum_latency is 13.5 microseconds.

[0031] Also, lower bounds, herein called “minimum_packets” and“minimum_latency,” may be placed on IMFC and IML, respectively.Illustrative values for minimum packets and minimum_latency are 1 packetand 4.5 microseconds, respectively. In this embodiment of the invention,latency values are restricted to multiples of 4.5 microseconds. Thistype of restriction may be expressed as another parameter,“incremental_latency.” In other embodiments (e.g., for a different typeof processor or computer system), a different incremental latency may beapplied, and/or a user may not be able to set a lower bound on IMFC orIML.

[0032] In one embodiment of the invention, a maximum Fallback LatencySensitivity (maximum_FLS) parameter is exposed to a user. In thisembodiment, the FLS parameter is expressed as a number of interrupts.Operation of an FLS mechanism or process, as explained in detail below,helps alleviate, or suppress, an inefficient pattern of adjustments tointerrupt coalescing parameters.

[0033] Illustratively, when a communication interface is initialized,its IMFC is set to a user-supplied value for minimum_packets, and IML isset to a user-supplied value for maximum_latency. Alternatively, eitheror both IMFC and IML may be set to some default or intermediate values(e.g., between minimum_packets and maximum_packets, and between minimumlatency and maximum_latency). During operation of a method of theinvention, IMFC and IML are dynamically adjusted according to the typeor pattern of traffic forwarded to the host from the communicationinterface.

[0034] While determining an appropriate new value for an interruptcoalescing parameter, the interrupt handler makes use of a “Trend” valueor parameter as a dynamic representation of traffic received from thecommunication interface. More particularly, Trend indicates whether oneor more recent interrupts have been issued with full complements ofpackets (i.e., a number of packets at least equal to IMFC). In otherwords, Trend indicates how the number of packets received with one ormore preceding interrupts compares to the values of IMFC at the time ofthe interrupts. In one implementation, the value of Trend is an integer,and therefore may be negative, positive or zero.

[0035] In one embodiment of the invention, as high numbers of packets,frames, cells or other communications are received, the interrupthandler receives a full load of packets with each interrupt it services.This means that the communication interface's IMFC parameter iscontinually met, and may be a sign that even more packets could beforwarded with each interrupt. The value of the Trend parameter willincrease, and may become more and more positive each time the interrupthandler receives a full load of packets. Conversely, each time thenumber of packets received with an interrupt is less than IMFC, Trend isdecreased, and may become more and more negative, to indicate a negativecorrelation between IMFC and the number of packets being received.

[0036] If the traffic “trend” reverses polarity, Trend may be set tozero. For example, if Trend is positive, and then the interrupt handlerreceives less than a full set of packets (i.e., less than IMFC) with aninterrupt, Trend may be set to zero. Or, if Trend is negative, and theinterrupt handler receives a full set of packets, this also may causeTrend to be set to zero. Resetting Trend to zero may prepare it tochange polarity to quickly reflect a change in workload (e.g., from bulkdata transfer to request-response, or vice versa).

[0037] As one skilled in the art will appreciate, an interrupt handlermay be able to determine the cause of an interrupt received from acommunication interface by comparing the number of packets received withan interrupt to the interface's IMFC. If the number of packets is lessthan IMFC, then it is likely that the interrupt was signaled because theinterface's IML parameter expired. Conversely, if the number of packetsreceived is at least equal to IMFC, then it is likely that the interruptwas issued because the IMFC parameter was reached.

[0038] In one embodiment of the invention, each time an interruptassociated with a packet transfer is received, and the interrupt handleris called, the interrupt handler compares the number of packets receivedwith the interrupt to the current IMFC setting. Then the current Trendis examined. Unless the number of received packets contradicts thetrend, in which case Trend is zeroed and the interrupt handler canfinish any other interrupt-related tasks (e.g., processing the packets),the IMFC is combined with the current Trend (or some proportionatevalue) to produce a new IMFC value. Then, Trend may be incremented ordecremented to generate a new Trend value. Finally, the IMFC parameteror register of the communication interface is updated to (e.g.,overwritten by) the new IMFC value and the interrupt handler cancontinue its work. The interface's IML parameter may also be updated.

[0039] Between its servicing of interrupts, various operating parametersor values used by the interrupt handler or device driver to adjust aninterrupt coalescing parameter (e.g., IMFC, IML, Trend, minimum_latency,maximum_packets, incremental_latency, various counters) may be stored aspart of a device driver's information structure. In particular, for eachcommunication interface, a separate set of parameters may be maintainedby its driver.

[0040]FIG. 2 is a flowchart demonstrating a method of adjustinginterrupt coalescing parameters of a communication interface, accordingto one embodiment of the invention. The illustrated method is primarilyapplied by a device driver or interrupt handling routine executed by ahost processor that receives interrupts when the communication interfacepasses one or more frames, packets or other communications to the host.

[0041] In state 202, a first interrupt is received from thecommunication interface, along with one or more frames. The interruptmay have been generated because the interface accumulated a number offrames equivalent to its current IMFC setting, or because a latencytimer set to IML expired.

[0042] In state 204, the interrupt handler compares the number ofreceived frames, N, to the current IMFC setting. If N≧IMFC, the methodadvances to state 214; otherwise (i.e., N<IMFC), the method continues atstate 206.

[0043] In state 206, the number of frames received with the interrupt isless than the maximum that could have been sent. This indicates that theinterrupt was issued because a latency timer (e.g., IML) expired. Thismay indicate that IMFC is set too high for the current flow ofcommunication traffic. Therefore, the interrupt handler determineswhether the current trend, T, is less than or equal to 0, which wouldindicate that at least the previous interrupt also arrived with fewerthan IMFC frames. If T>0, the method advances to state 222.

[0044] Otherwise, if T≦0, in order to allow IMFC to be decreased, ordecreased further, in state 208 IMFC is adjusted by the value of thetrend parameter (i.e., IMFC=IMFC+T). Because T is no greater than zero,IMFC will not increase, and may instead decrease.

[0045] However, in the illustrated embodiment of the invention, theminimum value that may be assigned to IMFC is determined by theparameter minimum_packets (e.g., one). Thus, if combining IMFC and Twould yield a new IMFC value less than the minimum, IMFC is set to theminimum.

[0046] In state 210, because N<IMFC, the trend value is decremented(e.g., T=T−1).

[0047] In state 212, the interrupt handler updates one or more interruptcoalescing parameters of the communication interface. In particular, theinterrupt handler sets the interface's IMFC value to the newly computedIMFC. The method ends after state 212.

[0048] In state 214, the number of frames received with the interrupt isat least equal to the maximum that the communication interface couldsend (i.e., IMFC), which indicates that IMFC may be too low for thecurrent traffic flow. The interrupt handler therefore determines whetherT≧0, to compare the present situation is the continuation of a trend ofreceiving the maximum number of frames. If T<0, the illustrated methodcontinues at state 222; otherwise, the method continues at state 216.

[0049] In state 216, IMFC is increased by the trend value (i.e.,IMFC=IMFC+T), to allow the communication interface to send more frameswith the next interrupt.

[0050] In state 218, T is incremented (e.g., T=T+1).

[0051] In state 220, the interrupt handler updates one or more interruptcoalescing parameters of the communication interface. In particular, theinterrupt handler sets the interface's IMFC value to the newly computedIMFC. The method ends after state 220.

[0052] In state 222, the trend, T, is set to zero (i.e., T=0).Illustratively, this is done if the number of frames received by theinterrupt handler contradicts the trend. Thus, if the maximum number offrames is received, yet the trend is negative, or if less than themaximum number of frames is received, but the trend is positive, theinterrupt handler will set the trend to zero. The method then ends.

[0053] TABLE 1 illustrates an application of the method of FIG. 2. “INT”is an ordinal index representing a sequence of interrupts. “Old Trend”and “Old IMFC” represent the values of Trend and IMFC before the currentinterrupt (e.g., set during the previous interrupt). “Frames” indicatesthe number of frames received at the host with the current interrupt.

[0054] “New Trend” and “New IMFC” represent the new IMFC and Trendvalues generated by the interrupt handler. As described above, the valueof New Trend depends on Old Trend and the relationship between Framesand Old IMFC. The value of New IMFC depends on Old Trend and Old IMFC.“Total Frames” is a cumulative count of the number of frames received.TABLE 1 Old Old New New Total INT Trend IMFC Frames Trend IMFC Frames 00 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 3 4 4 3 3 4 4 4 7 8 4 4 7 7 5 11 15 55 11 11 6 16 26 6 6 16 16 7 22 42 7 7 22 22 8 24 64 8 8 24 8 0 24 72 9 024 4 −1 24 76 10 −1 24 4 −2 23 80 11 −2 23 12 −3 21 92 12 −3 21 20 −4 18112 13 −4 18 12 −5 14 124 14 −5 14 4 −6 9 128

[0055] TABLE 1 illustrates how IMFC and Trend may increase whensuccessive interrupts arrive with full complements of packets. In thisexample, maximum_packets is set to 24, which is reached during theprocessing of interrupt number 7. The Trend value then swings frompositive to negative as a series of interrupts is received with packetloads that are less than IMFC. The IMFC parameter then steadilydecreases as long as interrupts are received without full packets loads.

[0056] The maximum_FLS (Fallback Latency Sensitivity) parameterintroduced above may be used in an embodiment of the invention toprevent a “hunting” pattern of adjustments to interrupt coalescingparameters (e.g., IMFC), in which IMFC “hunts” for an appropriate value.

[0057] In particular, when IMFC is at its minimum value, such as one,IMFC will be increased by one (e.g., to two) after a single packet orcommunication is received. This adjustment to IMFC prepares thecommunication interface to handle an influx of packets (e.g., a bulkdata transfer pattern of traffic). However, if a request-responsepattern is experienced instead, which may be evidenced by the receipt ofonly one packet during each successive interrupt, then each packetreceived while IMFC is at its incremented value (e.g., two) will bedelayed, because its associated interrupt will be issued only when thelatency timer (e.g., IML) expires. Because only one packet is receivedduring each interrupt, the increase in IMFC causes inefficient operationof the interface.

[0058] This is a special case of the situation in which the number ofpackets received is less than IMFC. Processing of the packet(s) isdelayed because an interrupt is not issued until a latency timerexpires. In contrast, when IMFC is set to a minimum value of one and asingle packet is received, an interrupt is issued right away.

[0059]FIG. 3A is a graph of IMFC adjustments for successive interrupts,and exhibits an illustrative hunting pattern spanning severalinterrupts. TABLE 2 reflects adjustments to IMFC and Trend made duringservicing of the interrupts, and the number of packets received witheach interrupt. TABLE 2 Old Old New New Total INT Trend IMFC FramesTrend IMFC Frames 0 0 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 1 0 4 3 3 0 4 1 −1 44 4 −1 4 1 −2 3 5 5 −2 3 1 −3 1 6 6 −3 1 1 0 1 7 7 0 1 1 1 1 8 8 1 1 1 22 9 9 2 2 1 0 4 10 10  0 4 1 −1 4 11

[0060] For each interrupt depicted in FIG. 3A, the interrupt handlerreceives just one packet, which may indicate a request-responsecommunication environment. At interrupt I₀, because the single interruptmatches the current IMFC value, Trend is incremented to record thatoccurrence and allow IMFC to grow, in case more than one packet could betransferred from the communication interface to the host at a time.During interrupt I₁, Trend is incremented again because the singlereceived packet matched IMFC, and so the value of IMFC is increased. Atinterrupt I₂, even though Trend is now zeroed—because the number ofreceived packets (i.e., 1) is less than IMFC—IMFC increases again due tothe magnitude of Trend. IMFC levels off during I₃, and Trend then swingsnegative. This allows IMFC to fall back to its minimum value duringinterrupts I₄, I₅ and I₆. The “hunting” pattern then resumes (if thesame traffic pattern continues).

[0061] In one embodiment of the invention, the maximum_FLS parameter isused to initialize an FLS counter when IMFC is increased from itsminimum value. Illustratively, a suitable value for maximum_FLS isthree. In this embodiment, the minimum value of IMFC is one, but inother embodiments of the invention, a different minimum value may beemployed.

[0062] In one alternative embodiment of the invention, activation of theFLS mechanism requires not only an increase in IMFC from its minimumvalue, but also the receipt of a number of packets equal to IMFC. Thus,in this embodiment, if the number of packets received during theinterrupt in which IMFC increases from its minimum value is less than(or greater than) IMFC, the FLS mechanism does not kick in.

[0063] After being initialized, the FLS counter decrements by one witheach successive interrupt handled, until reaching zero, at which timethe FLS mechanism becomes quiescent. Until the FLS counter reaches zero,if an interrupt is issued because the latency timer (e.g., IML) of thecommunication interface expired, then the Trend value is set to −1 andIMFC is set to 1. Illustratively, the interrupt handler can determinethat an interrupt was received because of expiration of the latencytimer if the number of packets received with the interrupt is less thanIMFC.

[0064] Also, when the FLS counter is initialized, IML is set to aminimum value which, in this embodiment, is 4.5 microseconds. Each timethe FLS counter is decremented, IML is increased toward its maximum(i.e., maximum_latency), by the value of incremental_latency (if such aparameter is set). If IML is restricted to multiples of 4.5 microsecondsin this embodiment, it grows from 4.5 microseconds to 9.0 microsecondsto 13.5 microseconds, etc. When the FLS counter reaches zero, IML isreset to its “normal” value which, in this embodiment, is equivalent tomaximum_latency. Decreasing the amount of time between interrupts helppromote a rapid return of IMFC to minimum_packets if a low rate ofpacket arrival continues.

[0065]FIG. 3B and TABLE 3 reflect the application of an FLS mechanism inan embodiment of the invention, for the same traffic pattern reflectedin FIG. 3A and TABLE 2. TABLE 3 includes additional columns showing thevalues of the FLS counter and IML (in microseconds). In this example,maximum_FLS=3 and, before interrupt number 0, FLS (the FLS counter)=0and IML is equal to maximum_latency (e.g., 13.5 microseconds).Minimum_latency and incremental_latency are both 4.5 microseconds.Minimum_packets=1. TABLE 3 Old Old New New New New Total INT Trend IMFCFrames Trend IMFC IML FLS Frames 0 0 1 1 1 1 13.5 0 1 1 1 1 1 2 2 4.5 32 2 2 2 1 −1  1 9.0 2 3 3 −1  1 1 0 1 13.5 1 4 4 0 1 1 1 1 13.5 0 5 5 11 1 2 2 4.5 3 6 6 2 2 1 −1  1 9.0 2 7

[0066] In comparison to FIG. 3A, the graph of FIG. 3B shows a much moreefficient treatment of request-response traffic, and a greatlyattenuated hunting pattern. In particular, because IML is temporarilyreduced during application of the FLS mechanism, and because IMFC israpidly returned to its minimum value, the latency experienced bypackets received at the communication interface is substantiallyreduced.

[0067]FIG. 4 demonstrates, in greater detail, a method of automaticallyand dynamically adjusting interrupt coalescing parameters (e.g., IMFC,IML) of a communication interface, according to the dynamic workload ofthe interface, in one embodiment of the invention.

[0068] In state 402, the interrupt handler or device driver is called,invoked or woken to handle an interrupt from a network interface orother communication interface. The interrupt was signaled either becausethe network interface accumulated a number of frames, packets or othercommunications equal to its current IMFC setting or because a period oftime equal to its current IML setting elapsed after receipt of a frame.

[0069] In state 404, the interrupt handler examines an FLS counter todetermine if it is greater than 0. If it is greater than zero, then theFLS mechanism is active, and the method continues at state 406;otherwise, the method advances to state 408.

[0070] In state 406, the interrupt handler increases IML (e.g., by thevalue of incremental_latency), but not beyond the value ofmaximum_latency. The interrupt handler also decrements the FLS counterby one, but no lower than zero in this embodiment.

[0071] In state 408, the interrupt handler compares the current IMFCsetting of the network interface to the number of frames received withthe interrupt. If the number of frames is less than the current IMFC,the illustrated method advances to state 430.

[0072] Otherwise, in state 410, the current interrupt was issued becausethe network interface accumulated a number of frames at least equal toIMFC. The interrupt handler examines the current Trend value. If Trendis zero or positive, which indicates that the amount of frames receivedwith the current interrupt (i.e., >=IMFC) matches the recent trend, themethod advances to state 414.

[0073] If Trend is negative, indicating that the network interface hasnot been sending a full complement of frames (i.e., equivalent to IMFC)with recent interrupts, in state 412 Trend is reset to zero and themethod ends.

[0074] In state 414, a new IMFC value is calculated by adding thecurrent IMFC value and the value of Trend. However, IMFC will not beincreased beyond the parameter maximum_packets.

[0075] In state 416, the interrupt handler determines whether IMFC hasjust been increased from minimum_packets (e.g., one). If so, the methodcontinues at state 418; otherwise, it proceeds to state 420. In otherembodiments, the interrupt handler may test for other conditions. Forexample, in one alternative embodiment, the interrupt handlerspecifically determines whether IMFC has just been increased from one totwo.

[0076] In state 418, an FLS mechanism or scheme is activated. Therefore,IML is set to a minimum value (e.g., minimum_latency), such as 4.5microseconds, and an FLS counter is initialized to maximum FLS (e.g.,three).

[0077] In state 420, the value of Trend is incremented (e.g., by one).

[0078] In state 422, one or more interrupt coalescing parameter values(e.g., the new IMFC and IML values) are written into the networkinterface to adjust the circumstances under which the interface willissue an interrupt, in an attempt to better match the interrupts to theactual traffic pattern and prevent or suppress an inefficient huntingpattern. The method then ends.

[0079] In state 430, the number of frames received with the currentinterrupt is less than the current IMFC value. The interrupt handlerexamines the FLS counter to see if the FLS mechanism is still active(e.g., is FLS>0?). If the FLS mechanism is no longer active, theillustrated method advances to state 436.

[0080] Otherwise, in state 432, the interrupt handler determines whethermore than a minimum number of frames (e.g., one) were received with thecurrent interrupt. If so, the method advances to state 436.

[0081] In state 434, the conditions for IMFC fall back have beensatisfied. In particular, for this embodiment of the invention, the FLScounter is greater than zero, and the minimum number of frames was justreceived. Therefore, the interrupt handler sets Trend to a negativevalue (e.g., −1), resets IMFC to its minimum (e.g., minimum_packets) andsets IML to its maximum (e.g., maximum_latency). The illustrated methodthen advances to state 442.

[0082] In state 436, the interrupt handler determines whether thecurrent Trend is positive. If so, then the current complement of frames(i.e., <IMFC) conflicts with the trend and therefore Trend is reset tozero in state 444 and the method ends.

[0083] Otherwise, in state 438, a new IMFC value is computed as the sumof the current IMFC value and Trend. However, IMFC will not be decreasedbelow minimum_packets.

[0084] In state 440, the value of Trend is decremented (e.g., by one).

[0085] In state 442, the network interface is dynamically updated withone or more new interrupt coalescing parameter values (e.g., IMFC, IML).The method then ends.

[0086] In one embodiment of the invention, an interrupt coalescingparameter may be dynamically adjusted based on the workload of a hostprocessor in addition to, or instead of, the workload of a communicationinterface. In this embodiment, the proportion of time the processor isidle is monitored. As the processor's idle time—or percentage of timespent idle—increases, a parameter may be adjusted to reduce theinterrupt-processing burden of the processor. This embodiment of theinvention is suitable for multi-processor as well as single processorcomputer systems.

[0087] In an implementation of this embodiment, when an interrupt from acommunication interface is processed, the device driver or interrupthandler accesses performance status data regarding the processor. Fromthe data, the proportion of the processor's time it has been idle can bedetermined. Its idle time may be retrieved during every interrupt orwith some other frequency (e.g., every second or third interrupt).

[0088] In this implementation, the interface's IML value is adjustedupward when the processor idle time percentage reaches or falls below athreshold. Multiple thresholds may be defined, so that IML may beincreased multiple times as the idle time percentage continues to fall.Similarly, IML may be decreased as the percentage of time the processoris idle rises. By increasing IML as the processor becomes busier, fewerinterrupts may be sent to the processor, thereby helping to reduce itsburden. In other implementations of this embodiment, other operatingand/or interrupt coalescing parameters may be adjusted as theprocessor's workload increases (e.g., IMFC, maximum_FLS,incremental_latency).

[0089] In addition to reducing the number of interrupts issued overtime, another possible benefit of increasing the IML setting is toincrease the number of packets or other communications received andprocessed during each interrupt.

[0090] The idle time percentage threshold(s) and corresponding latencyvalue(s) of a communication interface may be stored as operatingparameters, and may be tunable by a user. For example, one or more“idle_thresholdX” and “idle_latencyX” values may be maintained, whereinX may be an integer. TABLE 4 lists idle_threshold and idle_latencyvalues that may be employed in an implementation of this embodiment ofthe invention. The processor's proportion of time spent idle may berepresented as Idle %. TABLE 4 X idle_thresholdX idle_latencyX 1 50  302 40 180 3 30 360 4 20 640 5 10 1280 

[0091] In the implantation reflected in TABLE 4, the normalminimum_latency and maximum_latency operating parameters may be used todetermine IML as long as the processor spends more than half (i.e., 50%)of its time idle. However, when Idle % falls below 50% (or other initialthreshold), IML will be adjusted accordingly. The indicated idle_latencyvalues may be expressed as multiples to be applied to a basic orincremental latency. Thus, for idle_latency2, the value 180 may beinterpreted to mean 180 times the shortest latency period (e.g., 4.5microseconds). Alternatively, an idle_latency value may be interpretedas a number of microseconds, or other units, of latency to be applied.

[0092] Illustratively, the lowest idle_thresholdX that is greater thanor equal to Idle % will be applied. Thus, if Idle %=21%, idle_threshold3is indicated and idle_latency3 may be applied.

[0093] In this implementation, the indicated latency (i.e.,idle_latencyx) may be used to overwrite any of the operating parameters(e.g., minimum_latency, maximum_latency), or may be assigned directly toIML as long as Idle % is below the applicable threshold.

[0094] In another embodiment of the invention, processor “busy”time—rather than idle time—may be monitored. For example, the processorworkload could be interpreted as being proportional to the time spent onsystem tasks (e.g., “kernel time,” “system time”) or other types oftasks that may be considered relatively high in priority. In thisembodiment, IML may be increased when the processor workload rises abovea certain threshold (e.g., 50%). And, IML could be increased if/as theworkload continues to rise.

[0095]FIG. 5 demonstrates a method of adjusting an interrupt coalescingparameter (e.g., IML) according to a processor's workload, according toone embodiment of the invention. The illustrated method may be readilymodified or adapted for use with the FLS mechanism as described above inconjunction with FIGS. 4A-B.

[0096] In state 502, a first interrupt is received from thecommunication interface, along with one or more frames. The interruptmay have been generated because the interface accumulated a number offrames equivalent to its current IMFC setting, or because a latencytimer set to IML expired. In response to the interrupt, an interrupthandler or device driver for the communication interface is invoked.

[0097] In state 504, the interrupt handler determines the number offrames, N, that were received with the interrupt.

[0098] In state 506, the relation between N and IMFC is determined, andis compared with the current Trend. If T<0 and N>IMFC, or T>0 andN<IMFC, then the number of received packets is not consistent withTrend, and the method advances to state 512.

[0099] Otherwise, in state 508, the number of received packets isconsistent with Trend, and so IMFC is adjusted accordingly (i.e.,IMFC=IMFC+T). In state 510, Trend is adjusted (e.g., incremented ordecremented), depending on whether it is increasing or decreasing. Afterstate 510, the illustrated method continues at state 514.

[0100] In state 512, Trend is set to zero to indicate a reverse. Eithera full set of packets was received when fewer were expected, or lessthan a full set was received when a full set was expected.

[0101] In state 514, the interrupt handler or device driver accesses adata structure storing performance status data for the processor onwhich the handler or driver is executing. In particular, the percentageof processor time that is spent idle (i.e., Idle %) is read orcalculated from the available data.

[0102] In state 516, Idle % is compared to the first, highest or onlyidle threshold, depending on the configuration of the interface. If theprocessor's idle time is high enough (e.g., >50%), then there is no needto modify the normal method of calculating or setting IML, and so themethod advances to state 522.

[0103] Otherwise, in state 518, the lowest idle_threshold value that isgreater than Idle % is identified.

[0104] In state 520, the idle_latency value corresponding to theidle_threshold value is retrieved.

[0105] In state 522, one or more interrupt coalescing parameters may beupdated as necessary. Thus, if Idle % fell to a value less than anidle_threshold, a new, higher IML value may be applied. Illustratively,the applicable idle_latency may be copied directly to IML.

[0106] Conversely, if Idle % has increased such that it is now greaterthan any idle_threshold value(s), IML may be reset to maximum_latency orminimum_latency.

[0107] The foregoing descriptions of embodiments of the invention havebeen presented for purposes of illustration and description only. Theyare not intended to be exhaustive or to limit the invention to the formsdisclosed. Accordingly, the above disclosure is not intended to limitthe invention; the scope of the invention is defined by the appendedclaims.

What Is claimed Is:
 1. A method of dynamically adjusting interruptcoalescing behavior based on the workload of a host processor, themethod comprising: receiving a first interrupt at a host processor froma communication interface, wherein the interrupt is associated with thetransfer of one or more packets from the communication interface;obtaining an indication of a first proportion of time the processor wasidle; and if said first proportion is less than a first threshold,increasing a maximum allowable latency between successive interrupts,from the communication interface to the host processor, associated withthe transfer of one or more packets from the communication interface. 2.The method of claim 1, further comprising: defining one or morethresholds, including said first threshold; and for each of saidthresholds, specifying a latency; wherein said specified latency isinversely proportional to said threshold.
 3. The method of claim 1,wherein said indication identifies a percentage of time the processorwas idle.
 4. The method of claim 1, wherein said obtaining comprisesderiving said indication from a set of performance status data regardingthe host processor.
 5. The method of claim 1, wherein: prior to saidincreasing, the latency between successive interrupts, from thecommunication interface to the host processor, associated with thetransfer of one or more packets from the communication interface, isable to fluctuate between a minimum latency and a maximum latency; andsaid increasing a maximum allowable latency comprises increasing saidmaximum latency.
 6. The method of claim 5, wherein said increasing amaximum allowable latency further comprises increasing said minimumlatency.
 7. The method of claim 1, further comprising: receiving asecond interrupt at the host processor from the communication interface,wherein the interrupt is associated with the transfer of one or morepackets from the communication interface; obtaining an indication of asecond proportion of time the processor is idle; and if said secondproportion is greater than said first threshold, decreasing the maximumallowable latency between successive interrupts, from the communicationinterface to the host processor, associated with the transfer of one ormore packets from the communication interface.
 8. The method of claim 7,wherein said decreasing the maximum allowable latency comprisesresetting the maximum allowable latency to a default value.
 9. Acomputer readable storage medium storing instructions that, whenexecuted by a computer, cause the computer to perform a method ofdynamically adjusting interrupt coalescing behavior based on theworkload of a host processor, the method comprising: receiving a firstinterrupt at a host processor from a communication interface, whereinthe interrupt is associated with the transfer of one or more packetsfrom the communication interface; obtaining an indication of a firstproportion of time the processor was idle; and if said first proportionis less than a first threshold, increasing a maximum allowable latencybetween successive interrupts, from the communication interface to thehost processor, associated with the transfer of one or more packets fromthe communication interface.
 10. A method of dynamically controlling thesignaling of interrupts from a communication interface to a hostprocessor, the method comprising: receiving, at a host processor, afirst interrupt generated by a communication interface in connectionwith receipt of a first communication from a communication link;determining a workload of the host processor; and dynamically adjustingone or more of the following parameters on the communication interfacewithout reinitializing the communication interface: a first parameterconfigured to indicate a maximum number of communications thecommunication interface may accumulate before generating an interrupt tothe host processor; and a second parameter configured to indicate amaximum length of time the communication interface may wait afterreceiving a first communication before generating an interrupt to thehost processor.
 11. The method of claim 10, wherein said workloadcomprises an indication of host processor idle time.
 12. The method ofclaim 10, wherein said workload comprises a proportion of time that thehost processor has been idle.
 13. The method of claim 10, wherein saiddynamically adjusting comprises: identifying a workload thresholdexceeded by said workload; and retrieving a parameter value associatedwith said workload threshold.
 14. The method of claim 10, wherein: saidreceiving a first interrupt; said determining a workload of the hostprocessor; and said dynamically adjusting are performed by an interrupthandler configured to service the first interrupt.
 15. The method ofclaim 10, further comprising: defining one or more workload thresholds;and for each of said thresholds, specifying an associated parametervalue; wherein each said parameter value is proportional to saidassociated threshold.
 16. A computer readable storage medium storinginstructions that, when executed by a computer, cause the computer toperform a method of dynamically adjusting one or more communicationinterface parameters configured to control the signaling of interruptsfrom the communication interface to a host processor, the methodcomprising: receiving, at a host processor, a first interrupt generatedby a communication interface in connection with receipt of a firstcommunication from a communication link; determining a workload of thehost processor; and dynamically adjusting one or more of the followingparameters on the communication interface without reinitializing thecommunication interface: a first parameter configured to indicate amaximum number of communications the communication interface mayaccumulate before generating an interrupt to the host processor; and asecond parameter configured to indicate a maximum length of time thecommunication interface may wait after receiving a first communicationbefore generating an interrupt to the host processor.
 17. A method ofdynamically adjusting one or more interrupt coalescing parameters on acommunication interface according to a status of a host processorconfigured to receive interrupts from the communication interface,without reinitializing the communication interface, the methodcomprising: receiving at a host processor a first interrupt from thecommunication interface; identifying a first number of communicationsreceived with the first interrupt; determining a workload of the hostprocessor; comparing the first number of communications to a currentvalue of a first parameter of the communication interface, wherein saidfirst parameter comprises a number of communications the communicationinterface may accumulate before issuing an interrupt to the hostprocessor; examining a trend configured to indicate a relationshipbetween: a previous value of the first parameter at the time of aprevious interrupt; and a previous number of communications receivedwith the previous interrupt; adjusting said trend based on: saidcomparison of said first number of communications to said current valueof said first parameter; and a current value of said trend; if saidadjusted trend is not equal to a threshold trend: producing a first newvalue for said first parameter, based on said current value of saidfirst parameter and said trend; and dynamically updating said firstparameter of the communication interface with said first new value; andif said workload is greater than a first threshold, increasing a secondparameter of the communication interface, wherein said second parameterindicates a maximum period of time the communication interface may waitafter receiving a communication before generating an interrupt to thehost processor.
 18. The method of claim 17, wherein adjusting said trendcomprises setting said trend to said threshold trend.
 19. The method ofclaim 17, wherein adjusting said trend comprises incrementing saidtrend.
 20. The method of claim 17, wherein adjusting said trendcomprises decrementing said trend.
 21. The method of claim 17, whereinsaid threshold trend is zero.
 22. The method of claim 17, wherein saidproducing a first new value for said first parameter comprises: addingsaid current value of said first parameter and said current value ofsaid trend.
 23. The method of claim 17, wherein said dynamicallyupdating said first parameter comprises: writing said first new value ofsaid first parameter to the communication interface.
 24. The method ofclaim 17, further comprising: examining a fallback counter comprising anumber of interrupts during the processing of which said first new valueof said first parameter may be automatically set to a first minimumvalue; if said fallback counter is not equal to a final fallback countervalue: adjusting said fallback counter toward said final fallbackcounter value; and selecting a second new value for said secondparameter of the communication interface; and if said adjusted trend isnot equal to said threshold trend, dynamically updating said secondparameter of the communication interface with said second new value. 25.The method of claim 24, wherein said first minimum value is
 1. 26. Themethod of claim 24, wherein said final fallback counter value is
 0. 27.The method of claim 24, wherein said adjusting said fallback countercomprises decrementing said fallback counter.
 28. The method of claim24, further comprising: if (said first number of communications is notless than said current value of said first parameter) and (said trend isnot negative): if said current value of said first parameter is equal tosaid first minimum value: setting said second new value of said secondparameter to a second minimum value; and setting said fallback counterto an initial fallback counter value.
 29. The method of claim 28,wherein said second minimum value equals a value by which said secondparameter is incrementable.
 30. The method of claim 28, wherein saidsecond minimum value is 4.5 microseconds.
 31. The method of claim 28,wherein said initial fallback counter is approximately
 3. 32. The methodof claim 24, further comprising: if (said first number of communicationsis less than said current value of said first parameter) and (saidfallback counter is not equal to said final fallback counter value): ifsaid first number of communications equals a minimum number ofcommunications: reversing said trend; setting said first new value ofsaid first parameter to said first minimum value; and setting saidsecond new value of said second parameter to a maximum value.
 33. Themethod of claim 32, wherein said reversing said trend comprises settingsaid trend to a negative value.
 34. A computer readable storage mediumstoring instructions that, when executed by a computer, cause thecomputer to perform a method of dynamically adjusting one or moreinterrupt coalescing parameters on a communication interface accordingto a status of a host processor configured to receive interrupts fromthe communication interface, without reinitializing the communicationinterface, the method comprising: receiving at a host processor a firstinterrupt from the communication interface; identifying a first numberof communications received with the first interrupt; determining aworkload of the host processor; comparing the first number ofcommunications to a current value of a first parameter of thecommunication interface, wherein said first parameter comprises a numberof communications the communication interface may accumulate beforeissuing an interrupt to the host processor; examining a trend configuredto indicate a relationship between: a previous value of the firstparameter at the time of a previous interrupt; and a previous number ofcommunications received with the previous interrupt; adjusting saidtrend based on: said comparison of said first number of communicationsto said current value of said first parameter; and a current value ofsaid trend; if said adjusted trend is not equal to a threshold trend:producing a first new value for said first parameter, based on saidcurrent value of said first parameter and said trend; and dynamicallyupdating said first parameter of the communication interface with saidfirst new value; and if said workload is greater than a first threshold,increasing a second parameter of the communication interface, whereinsaid second parameter indicates a maximum period of time thecommunication interface may wait after receiving a communication beforegenerating an interrupt to the host processor.
 35. A method ofdynamically adjusting a network interface parameter for coalescinginterrupts, the method comprising: receiving a first interrupt from anetwork interface; determining a number of frames, F, received inconjunction with said first interrupt; comparing said number of framesto a dynamic threshold, DF; identifying a trend, T, comprising aninteger representing a relationship between a number of frames receivedin conjunction with one or more interrupts previous to the firstinterrupt and the value of said dynamic threshold at the times of saidone or more previous interrupts; identifying a measure of idle time, I,of a host processor configured to receive said first interrupt and saidone or more previous interrupts; comparing said measure of idle time toa dynamic idle time threshold, DI; if F >= DF: if T < 0, setting T = 0;and if T >= 0: setting DF = DF + T; incrementing T; and dynamicallyupdating one or more parameters, on the network interface, that affectwhen the network interface may issue an interrupt to the host processor;and if F < DF: if T > 0, setting T = 0; and if T <= 0: setting DF = DF +T; decrementing T; and dynamically updating one or more parameters, onthe network interface, that affect when the network interface may issuean interrupt to the host processor; and if I < ID, dynamically updatingone or more parameters, on the network interface, that affect when thenetwork interface may issue an interrupt to the host processor.


36. The method of claim 35, wherein said one or more parameterscomprise: a first parameter configured to indicate a number of framesthe network interface may accumulate before issuing an interrupt. 37.The method of claim 36, wherein said updating one or more parameterscomprises setting said first parameter to DF.
 38. The method of claim35, wherein said one or more parameters comprise: a first parameterconfigured to indicate a period of time the network interface may wait,after receiving a first frame, before issuing an interrupt.
 39. Acomputer readable storage medium storing instructions that, whenexecuted by a computer, cause the computer to perform a method ofdynamically adjusting a network interface parameter for coalescinginterrupts, the method comprising: receiving a first interrupt from anetwork interface; determining a number of frames, F, received inconjunction with said first interrupt; comparing said number of framesto a dynamic threshold, DF; identifying a trend, T, comprising aninteger representing a relationship between a number of frames receivedin conjunction with one or more interrupts previous to the firstinterrupt and the value of said dynamic threshold at the times of saidone or more previous interrupts; identifying a measure of idle time, I,of a host processor configured to receive said first interrupt and saidone or more previous interrupts; comparing said measure of idle time toa dynamic idle time threshold, Dl; if F >= DF: if T < 0, setting T = 0;and if T >= 0: setting DF = DF + T; incrementing T; and dynamicallyupdating one or more parameters, on the network interface, that affectwhen the network interface may issue an interrupt to the host processor;and if F < DF: if T > 0, setting T = 0; and if T <= 0: setting DF = DF +T; decrementing T; and dynamically updating one or more parameters, onthe network interface, that affect when the network interface may issuean interrupt to the host processor; and if I < ID, dynamically updatingone or more parameters, on the network interface, that affect when thenetwork interface may issue an interrupt to the host processor.


40. A method of dynamically adjusting one or more network interfaceparameters for coalescing interrupts, the method comprising: receiving afirst interrupt from a network interface; if a counter >0, wherein saidcounter is a fallback counter: decrementing said counter; and increasinga latency, L; determining a number of network frames, F, received inconjunction with said first interrupt; comparing said number of networkframes to a dynamic threshold, DF; determining a trend, T, comprising aninteger representing a relationship between a number of frames receivedin conjunction with one or more interrupts previous to the firstinterrupt and the value of said dynamic threshold at the times of saidone or more previous interrupts; identifying a measure of idle time, I,of a host processor configured to receive said first interrupt and saidone or more previous interrupts; comparing said measure of idle time toa dynamic idle time threshold, DI; if F >= DF: if T < 0, setting T = 0;and if T >= 0: if DF = a minimum dynamic threshold: setting said counterto an initial value; and setting L = a minimum latency; setting DF =DF + T; incrementing T; and updating one or more parameters, on thenetwork interface, that affect when the network interface may issue aninterrupt; if F < DF: if (said counter > 0) & (F = a minimum number offrames): setting DF = said minimum dynamic threshold; setting L to amaximum latency; and setting T = a negative value; if (said counter <=0) & (T <= 0), setting T = 0; and if [(said counter <= 0) & (T > 0)] OR[(said counter > 0) & (F > said minimum number of frames)]: setting DF =DF + T; decrementing T; and updating one or more parameters, on thenetwork interface, that affect when the network interface may issue aninterrupt; and if I < ID, dynamically updating one or more parameters,on the network interface, that affect when the network interface mayissue an interrupt to the host processor.


41. The method of claim 40, wherein said one or more parameterscomprise: a first parameter configured to indicate a number of framesthe network interface may accumulate before issuing an interrupt. 42.The method of claim 41, wherein said updating one or more parameterscomprises setting said first parameter to DF.
 43. The method of claim40, wherein said one or more parameters comprise: a first parameterconfigured to indicate a period of time the network interface may wait,after receipt of a first frame, before issuing an interrupt.
 44. Themethod of claim 43, wherein said updating one or more parameterscomprises setting said first parameter to L.
 45. A computer readablestorage medium storing instructions that, when executed by a computer,cause the computer to perform a method of dynamically adjusting one ormore network interface parameters for coalescing interrupts, the methodcomprising: receiving a first interrupt from a network interface; if acounter >0, wherein said counter is a fallback counter: decrementingsaid counter; and increasing a latency, L; determining a number ofnetwork frames, F, received in conjunction with said first interrupt;comparing said number of network frames to a dynamic threshold, DF;determining a trend, T, comprising an integer representing arelationship between a number of frames received in conjunction with oneor more interrupts previous to the first interrupt and the value of saiddynamic threshold at the times of said one or more previous interrupts;identifying a measure of idle time, I, of a host processor configured toreceive said first interrupt and said one or more previous interrupts;comparing said measure of idle time to a dynamic idle time threshold,DI; if F >= DF: if T < 0, setting T = 0; and if T >= 0: if DF = aminimum dynamic threshold: setting said counter to an initial value; andsetting L = a minimum latency; setting DF = DF + T; incrementing T; andupdating one or more parameters, on the network interface, that affectwhen the network interface may issue an interrupt; if F < DF: if (saidcounter > 0) & (F = a minimum number of frames): setting DF = saidminimum dynamic threshold; setting L to a maximum latency; and setting T= a negative value; if (said counter <= 0) & (T <= 0), setting T = 0;and if [(said counter <= 0) & (T > 0)] OR [(said counter > 0) & (F >said minimum number of frames)]: setting DF = DF + T; decrementing T;and updating one or more parameters, on the network interface, thataffect when the network interface may issue an interrupt; and if I < ID,dynamically updating one or more parameters, on the network interface,that affect when the network interface may issue an interrupt to thehost processor.


46. An apparatus for dynamically adjusting one or more parameters of acommunication interface configured to control interrupt coalescingbehavior of the communication interface, comprising: a processor; aninterrupt handler routine executable by the processor in response to aninterrupt from a communication interface; a first value corresponding toa first parameter of the communication interface, wherein said firstparameter comprises a number of communications the communicationinterface may accumulate before signaling an interrupt to the processor;and a second value corresponding to a second parameter of thecommunication interface, wherein said second parameter indicates aperiod of time the communication interface may wait before signaling aninterrupt to the processor; wherein the interrupt handler routine isconfigured to adjust one or more of said first value and said secondvalue, and dynamically update one or more of said first parameter andsaid second parameter accordingly, based on a workload of the processor.47. The apparatus of claim 46, wherein the interrupt handler routine isfurther configured to determine said processor workload.
 48. Theapparatus of claim 46, wherein said processor workload comprises anindication of a proportion of time the processor has been idle.
 49. Theapparatus of claim 46, wherein the interrupt handler routine is furtherconfigured to adjust one or more of said first value and said secondvalue, and dynamically update one or more of said first parameter andsaid second parameter accordingly, based on a pattern of communicationsreceived at the processor from the communication interface.
 50. Theapparatus of claim 46, further comprising: a trend value configured toindicate a correlation between a number of communications previouslyreceived from the communication interface and said first value when thenumber of communications was received.
 51. The apparatus of claim 46,wherein said trend value is configured to become positive when aplurality of sequential interrupts received at the processor from thecommunication interface are received with numbers of communications atleast equivalent to values of said first value at the times saidsequential interrupts are received.
 52. The apparatus of claim 51,wherein said trend value is configured to become negative when aplurality of sequential interrupts received at the processor from thecommunication interface are received with numbers of communications lessthan values of said first value at the times said sequential interruptsare received.
 53. The apparatus of claim 52, wherein said trend value isconfigured to be reset to a threshold trend value when one of: saidtrend value is positive and a first interrupt is received from thecommunication interface with a first number of communications less thansaid first value; and said trend value is negative and a secondinterrupt is received from the communication interface with a secondnumber of communications greater than or equal to said first value. 54.The apparatus of claim 50, wherein said first value is configured toincrease after said trend value increases and decrease after said trendvalue decreases.
 55. A computer system for controlling the issuance ofinterrupts associated with the receipt of communications, the computersystem comprising: a communication interface configured to receivecommunications from a communication link; an interrupt handlerconfigured to handle interrupts generated in response to receipt of saidcommunications at the communication interface; and a processorconfigured to execute said interrupt handler; wherein said interrupthandler is configured to control the issuance of said interrupts bymaintaining a latency parameter indicating a length of time thecommunication interface may wait, after receiving one or morecommunications, before issuing a corresponding interrupt; and whereinsaid interrupt handler periodically dynamically adjusts said latencyparameter in accordance with a workload of said processor.
 56. Thecomputer system of claim 55, wherein said interrupt hander adjusts saidlatency parameter by setting said latency parameter in proportion tosaid workload.
 57. The computer system of claim 55, wherein saidinterrupt hander adjusts said latency parameter by: determining aproportion of time said processor has been idle; and if said proportionis less than a threshold, setting said latency parameter to a latencyvalue associated with said threshold.
 58. The computer system of claim55, wherein said interrupt handler is further configured to control theissuance of said interrupts by maintaining a first parameter indicatinga number of communications the communication interface may receivebefore issuing a corresponding interrupt; and wherein said interrupthandler periodically dynamically adjusts said first parameter inaccordance with a trend configured to indicate, for one or moreinterrupts, a relation between: a value of the first parameter at thetime of the interrupt; and a number of communications received beforethe interrupt was issued.